-
Notifications
You must be signed in to change notification settings - Fork 0
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
#77 validation added. parent presence validation, title presence, uniqueness... #80
base: master
Are you sure you want to change the base?
Conversation
…ess (especially, project) (w/o join table)
수고하셨습니다~ 상위 객체에 대한 validation을 하고 싶다면 Custom Validation을 사용해야 합니다. ㅎㅎ Validation은 잘 거신 것 같은데, 이 기능을 추가함으로서 생기는 에러도 함께 처리해 줘야 할 것 같습니다. 아마 폼 입력과 관련한 많은 부분에서 에러가 날 것 같네요. ㅎㅎ |
확인했습니다. 근데 User모델에 거는 validation만큼 마이그레이션도 조정해줘야 하지 않을까요? (null: false 등) |
확인 했습니다! |
확인했습니다. |
@yhoonkim 사용자 Nickname에 '.'이 들어가도 라우팅에 문제 없게 해 주는 기능을 @MujinChae 멘티님이 추가했을 겁니다. 어디 브랜치였는지는 기억 안 나지만...(..) |
@yhoonkim 지금 마스터 브랜치에 user profile 나오는 부분에 있을겁니다 ㅎㅎ |
@shaynekang 상위 객체의 존재 여부는 persence를 걸면 될 것 같고, 상위 객체에 validation이 잘 짜여져있다고 할 때는 딱히 걸 일이 없을 것 같고, 이 상위 객체에 속해도 되는지 체크할 때 Custom Validation을 쓰는 경우가 떠오르는데 이게 맞나요? 한편, 상위 객체 혹은 하위 객체에 validates-associated 를 거는 경우는 보통 어떤 경우가 있는지 궁금합니다. 생각해보면 상위 객체에 걸 일이 있을 것 같지는 않지만요. |
@minhyeok92 분야에 따라 조금 다른데, 저는 데이터를 정말 깐간하게 검증해야 하는 분야가 아니라면(예: 의료, 증권, 결제) validation을 2중 ~ 3중으로 걸 필요는 없다고 봅니다. 오히려 생산성이 떨어지는 역효과가 난다고 생각해요. DB에 contraint는 걸어주지 않아도 무방할 것 같습니다. ㅎㅎ @fegs 아, 제가 코멘트를 잘못 이해했습니다. 저는 상위 객체에 validation을 넣는 방법에 대해서 질문하신 줄 알았네요. ㅎㅎ 경우에 따라서는 상위 객체가 반드시 들어가야 하는 경우도 있다고 생각합니다. 가령 지금의 Project같은 경우, 적어도 한 명의 Owner(User)가 있어야겠죠. 이런 경우는 |
현재는 history, todo에는 user, project presence 조건이 걸려있는데 이를 validates-associated로도 처리를 할 수 있다는 말씀이신가요? |
아, 맞다. |
레일즈캐스트 자료는 결제를 해야 되네요.(..) |
@shaynekang 음.. 조인 테이블의 경우는 별도로 validation을 걸지는 않나요? (..) |
음... 조인 테이블 거는 경우는 잘 못 봤네요. ㅎㄷ 저는 사실 Validation은 정말 필요한 것만 걸면 된다는 주의거든요. ㅋ(데이터가 중요한 의료, 금융, 결제 등이 아니라면) 만약 조인 테이블이나 두 개 이상의 테이블을 동시에 Create(or Update)하는 상황이 생긴다면, Form Object로 다 해결할 것 같아요. ㅎㅎ |
... (especially, project) (w/o join table)
#77
title이랑 상위 객체 (history면 속해 있는 project) 가 있는지 없는지 검사하는 부분을 추가했고, project의 경우는 title이 unique 해야하는 점을 추가했습니다. project title에는 조건을 달아서 정규식 체크도 해야할 것 같습니다.
한편 일반적으로 상위 객체에 대한 validation을 넣는지랑 join table에는 어떻게 넣어주는게 보통인지가 궁금합니다. (질문을 먼저 이슈에 하고 작업하는게 좋았으려나요?)